home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 107 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  1.7 KB

  1. Path: dawn.mmm.com!news
  2. From: kjhopps@mmm.com (Kevin J Hopps)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Constructor Exceptions
  5. Date: 2 Jan 1996 15:01:41 GMT
  6. Organization: 3M - St. Paul, MN  55144-1000 US
  7. Message-ID: <4cbhcl$kst@dawn.mmm.com>
  8. References: <4bud9g$pv5@oxy.rust.net>
  9. Reply-To: kjhopps@mmm.com
  10. X-Newsreader: TIN [version 1.2 PL2]
  11.  
  12. Paul Gunn (pgunn@mail.cbf.com) wrote:
  13.  
  14. > I use Microsoft Visual C++, and have been gradually making use of
  15. > exceptions in my code. I'm interested in using exceptions in my
  16. > constructor code, but according to a MS article, when an exception is
  17. > thrown from a constructor on a heap object, the memory will not be
  18. > freed.
  19.  
  20. > Is this behavior parculiar to the Microsoft implementation or is it
  21. > generally the case?
  22.  
  23. It is not generally the case.  Compilers that adhere to the standard
  24. will produce code that does not leak memory in this way.
  25.  
  26. > I couldn't find any other reference to this issue in the ARM or other
  27. > sources. In any event, it makes me very hesitant to throw exceptions
  28. > from my constructors. 
  29.  
  30. I understand your hesitance.  Exceptions are, IMHO, the best way to
  31. report errors from constructors and overloaded operators.  If your
  32. compiler does not do it right, you may have to report the error in
  33. some other way (such as an "ok()" function) or rework your constructor
  34. so that it cannot fail (possibly by deferring some operations).
  35. --
  36. Kevin J. Hopps                  e-mail: kjhopps@mmm.com
  37. 3M Company                      phone:  (612) 737-4643
  38. 3M Center, Bldg. 235-2D-57      fax:    (612) 737-2700
  39. St. Paul, MN 55144-1000         Opinions are my own.  I don't speak for 3M.
  40.     But 3M speaks for me -- I did not write the following line:
  41.  
  42. Opinions expressed herein are my own and may not represent those of 3M.
  43.